Apparatus and methods for managing key material in cryptographic assets

ABSTRACT

Apparatus and methods for managing key material in cryptographic assets are disclosed. The methods can include defining first key material to be delivered to a cryptographic asset, wherein the first key material has a cryptoperiod having an expiration. Second key material to be delivered to the cryptographic asset is also defined. An automatic delivery of the second key material is scheduled such that the second key material will be delivered automatically to the cryptographic asset at or before the expiration of the cryptoperiod of the first key material. The methods can include defining a set of equipment classes, and registering at least one cryptographic asset with each equipment class. Cryptographic assets selected from the registered cryptographic assets are grouped into secure communication services, thereby defining secure communication interfaces between the cryptographic assets. Key material for each communications interface is defined, and an automatic delivery of the key material to the selected cryptographic assets is scheduled. The apparatus and methods of the invention provide an integrated key management system suitable for managing key material in a plurality of heterogeneous cryptographic assets from a single system.

RELATED APPLICATIONS

[0001] This application claims priority from U.S. Provisional PatentApplication Serial No. 60/105,386, filed Oct. 23, 1998, the contents ofwhich are hereby incorporated by reference. The subject matter disclosedherein is related to the subject matter disclosed in copendingapplication Ser. No. ______ (attorney docket LCOM-0482), filed on evendate herewith.

FIELD OF THE INVENTION

[0002] The present invention relates generally to cryptography systems.More particularly, the present invention relates to an automated keymanagement system that includes apparatus and methods for managing keymaterial in heterogeneous cryptographic assets.

BACKGROUND OF THE INVENTION

[0003] As an organization's need to provide confidentiality andauthenticated access to a user's data increases, so does its need forcryptographic services. Cryptography provides a convenient way to ensurethat data can be accessed (either remotely or locally) only bylegitimate users with a valid “need to access,” and that this data isaccessed in a manner that keeps its content private to all but thelegitimate accessing party. As the number of cryptographic devices usedwithin an organization grows, the management of the key material neededto operate these devices becomes more difficult. Moreover, theorganization is typically required to perform both symmetric andasymmetric key management.

[0004] An example of an organization that requires secure management ofkey material for a heterogeneous set of cryptographic devices is a bank.Many banking customers require secure remote access to their accountbalances and authenticated requests for account withdrawals. The banksthemselves must be able to wire money from institution to institution ina secure and authenticated manner. Data confidentiality, data integrity,and data authenticity are obvious security requirements supporting thesebanking services.

[0005] Cryptography and cryptographic techniques provide a vehicle forachieving data confidentiality, data integrity, and data authenticity.As cryptography and cryptographic techniques are implemented, keymanagement naturally follows. Traditionally, key management has tendedto be a unique “stove pipe” function implemented in each cryptographicsystem (e.g., a wire transfer system) as a unique dedicated keymanagement system. The key management systems (which provide pointsolutions) are typically proprietary and are specifically tailored toone type of cryptographic equipment from one manufacturer. Additionally,existing key management systems tend to be highly user intensive. Forexample, distribution of key material to automated teller machines(ATMs) typically occurs via physical channels using two person control.

[0006] Traditionally, banks have addressed the key management needs foreach banking service (e.g., ATM transactions, Electronic FundsTransactions (EFTs), etc.) as a separate and distinct consideration. Asbanks expand their set of services, however, to include, for example,remote “home banking” and remote deployment of cash machines, each ofthese services will also require different key management to support thecryptography involved in implementing the service.

[0007]FIG. 1 provides an exemplary scenario in which a conventional keymanagement system is employed in a banking network. As shown, anacquiring bank 58 is in communication with an issuing bank 50. Issuingbank 50 can be, for example, a bank in which a particular customer holdsan account. Acquiring bank 58 can be, for example, a bank at which thecustomer initiates a transaction. For example, the customer mightwithdraw money from an ATM at acquiring bank 58. Acquiring bank 58communicates the transaction to issuing bank 50 so that the banks canreconcile the transaction between them. Acquiring bank 58 and issuingbank 50 can be the same bank, or different banks.

[0008] Typically, banks communicate with one another via a financialnetwork 54. Some well-known financial networks include Cirrus, Plus,S.W.I.F.T., etc. Financial network 54 facilitates the reconciliation oftransactions between acquiring bank 58 and issuing bank 50. As shown,issuing bank 50 is in communication with financial network 54 via apublic switched telephone network (PSTN) 52. Similarly, acquiring bank58 is in communication with financial network 54 via a PSTN 56.

[0009] As shown, acquiring bank 58 can be in communication with an ATM76, a home banking client 92, a wholesale banking terminal 64, and anynumber of other types of equipment. Preferably, acquiring bank 58includes a wholesale server 60 that communicates via a PSTN 62 withwholesale banking terminal 64. Wholesale banking terminal 64 can be acomputer or other workstation via which a wholesale banking operator cancontrol electronic funds transfers (EFTs) for example. Acquiring bank 58can also include an ATM host 72 that communicates via a PSTN 74 with ATM76. Acquiring bank 58 can also include a home banking server 88 thatinterfaces via a communications network 90 with a home banking client92. Typically, communications network 90 is the Internet, although itcould be any communications network, such as a LAN, WAN, or intranet.

[0010] To maintain privacy and security on the communications networkjust described, cryptography is typically employed to secure thecommunications links. FIG. 1 shows the “disjointed” key management ofeach banking service when a conventional key management system isemployed. That is, each banking service (ATM, EFT, home banking, etc.)makes use of a separate key management system that is dedicated to thatservice. The system as a whole, therefore, comprises a plurality of keymanagement systems, each of which is separately maintained.

[0011] For example, wholesale server 60 is also in communication via akey management (KM) interface 66 with a wholesale KM system 68.Wholesale KM system 68 is in communication via a KM interface 70 withwholesale banking terminal 64. Wholesale KM system 68 manages (i.e.,generates and distributes) key material for wholesale banking terminal64. Key material can include the key itself, as well as attributes thatdescribe the key, such as its name, version, key type, expiration date,etc.

[0012] KM interfaces 66 and 70 can be separate physical interfaces,although, in general, they need not be. KM interfaces 66 and 70 are“virtual” interfaces, i.e., they can include any vehicle by whichwholesale KM system 68 can manage key material to secure thecommunications link between wholesale banking terminal 64 and wholesaleserver 60.

[0013] Similarly, ATM 76 is in communication via a KM interface 78 withan ATM KM system 80. ATM KM system 80 manages the key material for ATM76. As shown, ATM host 72 can also interface with a network securityprocessor (NSP) 82. NSP 82 is in communication via a KM interface 84with an ATM host KM system 86. ATM host KM system 86 manages the keymaterial for ATM host 72. ATM KM system 80 and ATM host KM system 86typically share key material. Typically, ATM key management requires twoperson, physical delivery. That is, each of two persons is required tophysically deliver part of a “split” key to ATM 76. In this way, KMinterfaces 78 and 84 are not physical interfaces, but virtual.

[0014] As home banking typically occurs via the Internet, home bankingserver 88 is usually coupled to a secure sockets layer (SSL) accelerator98, which provides for secure communications over a public network suchas the Internet. A home banking KM system 94 communicates via a KMinterface 96 with home banking server 88. Home banking KM system 94manages the key material for home banking client 92 via KM interfaces93, 95.

[0015] To date, the limited number of ATMs and electronic transactioninterfaces has allowed the less comprehensive “point” key managementsystems to survive. With the explosion of remote ATMs (i.e., ATMslocated in non-bank locations), the addition of numerous remote users,and the subsequent key management needs of each (i.e., each userrequiring management of keying resources), the key management situationis fast becoming unmanageable. Additionally, the rapidity with whichcryptographic algorithms become obsolete exacerbates the key managementproblem. It is well known that key management systems typically evolvefrom a cryptographic product; however, developers of key managementsystems typical develop these systems to support a particularcryptographic device. Since a single cryptographic device usually cannotsupport all of a user's cryptographic needs, users are frequentlyrequired to manage many different types of devices using different keymanagement systems.

[0016] It would be advantageous, therefore, to organizations such asbanks to have a comprehensive integrated key management system thatefficiently and securely manages all banking key management needs (e.g.,from remote ATM to remote home banking user). That is, it would be muchmore efficient for an organization to use a single system that canhandle multiple devices, than it would be to use many different keymanagement systems to perform the same function. Similarly,consolidation and automation in a secure framework improves theefficiency and frequency of key management activities, thus making thecryptographic systems more secure. Thus, there is a need in the art foran automated, integrated, key management system for managing keymaterial for a plurality of heterogeneous cryptographic assets.

SUMMARY OF THE INVENTION

[0017] The present invention satisfies these needs in the art byproviding apparatus and methods for managing key material for aplurality of heterogeneous cryptographic assets. According to one aspectof the invention, a method for managing key material in cryptographicassets comprises defining first key material to be delivered to acryptographic asset, wherein the first key material has a cryptoperiodhaving an expiration. Second key material to be delivered to thecryptographic asset is also defined. Defining the first or second keymaterial can include defining a number of keys to be delivered to thecryptographic asset and, for each key to be delivered, defining a keytype. Defining the first or second key material can also includereceiving the first or second key material from a remote key managementsystem. The key material can be encrypted under a protection key andstored in the system.

[0018] An automatic delivery of the second key material to thecryptographic asset is scheduled such that the second key material willbe delivered automatically to the cryptographic asset at or before theexpiration of the cryptoperiod of the first key material. A distributionmethod can be associated with the cryptographic asset. Based on thedistribution method, a minimum lead time required to deliver the keymaterial to the cryptographic asset is determined. The automaticdelivery of the second key material to the cryptographic asset can thenbe scheduled based on the distribution method and on the minimum leadtime. The apparatus and methods of the invention can determine whetherthe key material was successfully delivered to the cryptographic asset.If not, then the key material is redelivered until it is successfullydelivered to the cryptographic asset.

[0019] To define a network of cryptographic assets, an operator of thesystem can first define a set of equipment classes. At least onecryptographic asset can then be registered with each equipment class.Cryptographic assets selected from the registered cryptographic assetscan then be grouped into secure communication services. Thus, securecommunication interfaces can be defined between the cryptographicassets.

[0020] In another aspect of the invention, a method is provided formanaging key material in a plurality of cryptographic assets having acommunications interface defined therebetween. According to this aspectof the invention, a key management interface is defined between acryptographic processor and the cryptographic assets. A cryptographicprocessor is used to generate key material to secure the communicationsinterface. The key material is then distributed from the cryptographicprocessor to the cryptographic assets via the key management interface.

[0021] In still another aspect of the invention, a method is providedfor managing key material for cryptographic assets that includesgenerating, via a cryptographic processor, key material for each of aplurality of heterogeneous cryptographic assets, and then distributingthe key material to the heterogeneous cryptographic assets via a keymanagement interface coupled to the cryptographic processor.

[0022] According to the invention, a method for managing key material incryptographic assets can include generating first key material, anddistributing the first key material to a cryptographic asset. Thecryptographic asset is monitored to determine, based on a cryptoperiodof the first key material, whether the first key material has expired.Second key material is also generated for the cryptographic asset, andif the first key material has expired, the second key material isautomatically distributed to the cryptographic asset.

[0023] In another aspect of the invention, a method for securing acommunications interface is provided. A set of equipment classes isdefined, with at least one cryptographic asset registered with eachequipment class. Cryptographic assets selected from the registeredcryptographic assets are grouped into secure communication services,thereby defining secure communication interfaces between thecryptographic assets. Key material for each communications interface isthen defined, and the automatic delivery of the key material to theselected cryptographic assets is scheduled.

[0024] Apparatus for managing key material for cryptographic assetsaccording to the invention comprises a cryptographic processor thatgenerates key material for each of a plurality of heterogeneouscryptographic assets, and a controller having a key managementinterface, that receives the key material from the cryptographicprocessor and distributes the key material to the heterogeneouscryptographic assets via the key management interface.

[0025] In another aspect of the invention, apparatus for managing keymaterial for cryptographic assets comprises a cryptographic processorthat defines first and second key material to be delivered to acryptographic asset, wherein the first key material has a cryptoperiodhaving an expiration, and a controller that schedules an automaticdelivery of the second key material to the cryptographic asset such thatthe second key material will be delivered automatically to thecryptographic asset at or before the expiration of the cryptoperiod.

[0026] Apparatus for managing key material for cryptographic assets caninclude computer executable instructions for performing a methodaccording to the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The foregoing summary, as well as the following detaileddescription of the preferred embodiments, is better understood when readin conjunction with the appended drawings. For the purpose ofillustrating the invention, there is shown in the drawings an embodimentthat is presently preferred, it being understood, however, that theinvention is not limited to the specific apparatus and methodsdisclosed.

[0028]FIG. 1 provides an exemplary scenario in which a conventional keymanagement system is employed.

[0029]FIG. 2 provides an exemplary scenario in which a key managementsystem according to the present invention is employed.

[0030]FIG. 3 is a software context diagram for a key management systemaccording to the present invention.

[0031] FIGS. 4A-4D provide a workflow diagram for a key managementsystem according to the present invention.

[0032]FIG. 5 depicts a software architecture for a preferred embodimentof the present invention.

[0033]FIG. 6 is a process flow for a preferred embodiment of the presentinvention.

[0034]FIG. 7 shows a human machine interface for a preferred embodimentof the present invention.

[0035]FIG. 8 is a flowchart of an automated scheduling process used inconjunction with the present invention.

[0036]FIG. 9 shows the connectivity of a remote rekey system.

[0037]FIG. 10 depicts a device initialization and key delivery process.

[0038]FIG. 11 is a flowchart of an IKMS initialization process.

[0039]FIG. 12 shows a simplified set of message exchanges that are usedto complete the Factory Initialization phase of a remote rekeyingprotocol according to the present invention.

[0040]FIG. 13 shows a simplified set of message exchanges that are usedto complete the Device Initialization phase of a remote rekeyingprotocol according to the present invention.

[0041]FIG. 14 shows a simplified set of message exchanges that are usedto deliver key material securely to a device.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0042] Overview

[0043]FIG. 2 provides an exemplary scenario in which an integrated keymanagement system (IKMS) according to the present invention is employed.FIG. 2 depicts an IKMS 100 supporting a plurality of banking servicesthat employ heterogeneous cryptographic assets. It should be understood,however, that the use of a bank is merely exemplary, and that theapparatus and methods of the present invention can be employed by anyorganization that manages cryptographic equipment.

[0044] As discussed above in connection with FIG. 1, an acquiring bank58 is in communication with an issuing bank 50 via a financial network54. Acquiring bank 58 and issuing bank 50 can be the same bank, ordifferent banks. Preferably, issuing bank 50 is in communication withfinancial network 54 via a public switched telephone network (PSTN) 52.Similarly, acquiring bank 58 is in communication with financial network54 via a PSTN 56. It should be understood, however, that PSTNs areexemplary, and that any public or private communications network can beused.

[0045] As shown, acquiring bank 58 can be in communication with an ATM76, a home banking client 92, a wholesale banking terminal 64, and anynumber of other types of equipment. Preferably, acquiring bank 58includes a wholesale server 60 that communicates via a PSTN 62 withwholesale banking terminal 64. Acquiring bank 58 can also include an ATMhost 72 that communicates via a PSTN 74 with ATM 76, and a home bankingserver 88 that interfaces via a communications network 90 with a homebanking client 92. Preferably, communications network 90 is theInternet, although it can be any communications network such as a LAN,WAN, or intranet.

[0046] In contradistinction to the scenario of FIG. 1, FIG. 2 shows the“integrated” key management of a plurality of banking services when akey management system according to the present invention is employed.That is, each banking service (ATM, EFT, home banking, etc.) makes useof the same key management system that manages key material for all thebanking services. Thus, there is no longer a need to maintain a separatekey management system for each banking service.

[0047] For example, as shown in FIG. 2, IKMS 100 is in communicationwith wholesale server 60 via a KM interface 66′ and with wholesalebanking terminal 64 via a KM interface 70′. Similarly, IKMS 100 is incommunication with home banking server 88 via a KM interface 96′, andwith home banking client 92 via a KM interface 95′ over communicationsnetwork 90. Finally, IKMS 100 is also in communication with ATM server72 via a KM interface 84′, and with ATM 76 via a KM interface 78′. Thus,a single IKMS is in communication with a plurality of equipment types,each of which requires, in general, different key management.

[0048] For example, as described above, ATMs typically requiretwo-person physical delivery of split key material, and employ symmetriccryptographic algorithms. Home banking systems, on the other hand,typically manage key material over the Internet and employ asymmetricalgorithms. Thus, the plurality of cryptographic assets that IKMS 100manages can be said to be heterogeneous. That is, in general, theyrequire different key material and employ different cryptographicalgorithms.

[0049] An integrated key management system according to the presentinvention provides a number of benefits. For example, it can support keygeneration and key distribution for numerous types of equipment and forboth symmetric and asymmetric algorithms. An “asymmetric” key algorithminvolves two separate keys (e.g., one key to encrypt and another todecrypt) that are based on a mathematical relationship in which one keycannot be calculated (at least in any reasonable amount of time) fromthe other key. In a “symmetric” algorithm, the encryption key and thedecryption key are typically the same.

[0050] By automating the management of key material, the IKMS can reduceoperating and maintenance costs associated with supporting multiple,“point” key management systems. The IKMS can also save time becausethere is no longer a need to have an operator intervene at every step ofthe process. The IKMS can provide secure storage of key material for aplurality of cryptographic assets, and thus, can allow for key recoveryduring disasters, equipment failure, law enforcement action, etc. It cansupport secure, automated distribution of keys to equipment on ascheduled basis, and rapid redistribution of previously distributed keymaterial to restore secure communications services. It can supportsecure key distribution to remote cryptographic equipment over bothpublic and private communications networks. Examples of publiccommunications networks include public switch telephone network (PSTNs),or the Internet. Examples of private communications networks includelocal area networks (LANs) or leased lines. Typically, leased lines arepart of the PSTN.

[0051] The IKMS can integrate multiple cryptographic activities in asingle workstation or network, and can support future growth of keymanagement capabilities, such as distribution methods and additionalalgorithm types, without adding new support systems.

[0052] Generally, the present invention focuses on the automatedmanagement of key material across an organization with a diverse (i.e.,heterogeneous) set of cryptographic assets. The IKMS can simplify thekey management process, while supporting the secure management of keymaterial, for a plurality of heterogeneous cryptographic devices. It canmanage key material for a variety of equipment types, and for a varietyof algorithms, over the entire life cycle of the key material (i.e.,from generation to destruction).

[0053] A preferred embodiment of the present invention includes bothhardware and software components. It can include a server or computerthat runs an operating system, a relational database, and key managementapplication software. Cryptographic functionality can be implemented ina cryptographic module, which can be implemented in hardware orsoftware. This cryptographic functionality can include the generation,encryption, decryption, randomization, and translation of key material(both symmetric and asymmetric) and of key distribution messages. Apreferred embodiment of the present invention includes a hardwarecryptographic module. An IKMS server and IKMS application softwareprovide control for the cryptographic hardware module.

[0054] The IKMS can operate as a single system, or it can interact withsimilar systems to form a key management network. In this way, keymaterial can be moved securely between systems to support backupoperations and to distribute management responsibilities. Thisarchitecture can support a variety of network organizations thatinclude, for example, centralized generation and distribution,centralized generation with distributed distribution, and distributedgeneration and distribution. Key material can be encrypted and sent fromone system to another via e-mail. Preferably, the key material isencrypted along with the message body containing the encrypted key data.This ensures confidentiality of the key management messages passedbetween systems.

[0055] An IKMS according to the present invention can provide secureremote rekey of cryptographic devices connected via public or privatenetworks. The implementation of this remote rekey capability cansimplify the key management of cryptographic devices that are remotefrom the key management center. Many cryptographic devices requirephysical twoperson delivery of key material (i.e., where two people arerequired to ensure that the secret key is, in fact, secret). Remoterekey can eliminate the need for anyone to visit the equipment duringthe keying process. The key can be delivered securely over a network ina manner that ensures that the secret key is not compromised.

[0056] Thus, the apparatus and methods of the present invention allowone or more users to generate, distribute, and manage cryptographic keymaterials for heterogeneous cryptographic assets within an organization,from a single or networked group of workstations or computers. Notably,the system can provide life cycle key management for each cryptographicasset it manages. Preferably, these life cycle management activitiesspan the entire life of the key material (i.e., from generation todestruction), and can include, for example, registration of accounts(i.e., the network of computers managing the key material), registrationof system operators, registration of equipment to receive the keymaterial, registration of equipment types, and registration of keyingservices (e.g., the cryptographic link between two or more pieces ofequipment).

[0057] The system can also manage automated scheduling of keygeneration, distribution, and replacement, and the generation of keymaterial for a variety of encryption algorithms (e.g., Data EncryptionStandard (DES), triple DES, Rivest-Shamir-Adleman (RSA), DSA, DiffieHellman, etc.). IKMS can import keys from “foreign” generation systems,and audit security critical events (such as distribution of key andcreation of key). The system can generate reports. such as key holdings,registered configuration of cryptographic networks, equipment holdings,etc. It can manage secure distribution of key material, automateddestruction of key material upon expiration/replacement, supersession ofkey material, secure remote rekey of equipment over open networks, andso on.

[0058] Thus, the apparatus and methods of the present invention can helpan organization improve its system's security, while adapting to theorganization's unique security policies. A preferred embodiment of thepresent invention includes a software management system, and acommercially available hardware cryptographic engine. The softwaremanagement system manages and tracks life cycle activities, and directsthe activities of the hardware cryptographic engine. The cryptographicengine performs encryption, decryption, and signature functions.

[0059] Significant features of this system include its ability tosecurely generate and store key material for a variety of equipment andalgorithm types. It is anticipated that the system should be able tomanage numerous types of cryptographic equipment from numerousmanufacturers and, preferably, it has a built-in ability to expand thesuite of equipment it can manage. The system has the ability to automatethe key generation and distribution processes based on informationrecorded in its database about the equipment and its connectivity. Itcan handle system failures by providing secure recovery methods forsecurely stored key material. It can securely archive key material tosupport key recovery. It can manage both symmetric and asymmetric keymaterial and equipment using either or both of these types of key. Itcan manage key material over its entire life (i.e., from generation todestruction), and it can support secure remote rekey over open (i.e.,public) networks. It controls cryptographic assets through a uniquedatabase-driven operator interface that is simple and straightforward touse. It can import key material from other systems for secure storageand secure distribution to equipment registered with this system.

[0060] Apparatus and Methods for Managing Key Material in HeterogeneousCryptographic Assets

[0061] This section describes a preferred embodiment of the apparatusand methods of the present invention. Generally, the services that IKMSprovides include accounting, registration (accounts, equipment type,equipment, and cryptographic equipment relationships), key generation,automated and manual secure key distribution, remote rekey, key import,key supersession, report generation, key management auditing, systemmaintenance, cryptographic support, secure key material storage, andmessaging.

[0062]FIG. 3 is a software context diagram for an integrated keymanagement system (IKMS) 100 according to the present invention. Asshown in FIG. 3, IKMS 100 can support a plurality of interfaces. Forexample, an operator interface 104 is used to enable the system (e.g,via operating system log-on and two user application log-on), toconfigure the system, to direct activities, and to establish automatedschedules. Once the system is enabled, automated activities can occurthrough other interfaces. Preferably, the system can support three typesof operators 106: operating system administrators, databaseadministrators, and IKMS specialists (i.e., operators of the IKMSapplication). Preferably, IKMS requires two IKMS specialists to belogged on simultaneously, although other log-on mechanisms can beimplemented depending on the needs of the individual implementation. Forexample, token access might be employed.

[0063] A “Cryptographic Processor Engine (CPE)” interface 108 supportscryptographic processing. CPE 110 can perform key generation, randomnumber generation, encryption, decryption, translation, and signing.IKMS application software 102 manages CPE 110 and directs its action.CPE 110 enhances security by isolating cryptographic functions to aprotected boundary and by accelerating cryptographic processes. The CPEfunction can be implemented as a hardware or software module. It isanticipated that a preferred embodiment will utilize a hardware modulethat interfaces through a PCI bus 108. One or more modules (or cards)can be used to provide the CPE function.

[0064] A “Floppy Disk” interface 116 supports distribution ofcryptographic material (keys and certificates) to commercialcryptographic equipment and other IKMS systems via a floppy disk orother removable data storage medium 118. Normally, floppy disk interface116 is used as a backup distribution interface.

[0065] An “Other IKMS Systems” interface 120 can be used to distributekey material, IKMS certificates, reports, and distribution confirmationmessages between IKMS accounts (i.e., other IKMS systems 122). Interface120 can be supported through e-mail, with the actual data beingtransmitted via an attachment. Interface 120 is also used to backupcritical IKMS data between one IKMS account and its backup IKMS account.Data backup is typically supported by TCP/IP with the data link betweenthe two accounts protected by encryption to ensure data privacy.

[0066] An “Impact Printer” interface 124 supports symmetric keydistribution to cryptographic devices requiring physical delivery of keymaterial (such as ATMs, financial switches, and NSPs). Physical keys aresplit, and each split is printed on a separate PIN mailer form usingprinter 126. The split keys are sent to two different people for manualentry into the cryptographic device. Interface 124 can also be used toprint key parts that can later be associated to form a key in the field.

[0067] An “ATM System” interface 128 is used to rekey an ATM 130 overthe network using a remote rekey process. Whenever a request for rekeyis received from an ATM Host, the requests can be validated and thenprocessed automatically—without operator intervention. A Diffie-Hellmankey exchange can be used to generate two unique session KEKs for therekey exchange. A KEK (key encryption key) is a key used to protectanother key. The new key (to be sent to the ATM) is encrypted in theKEK. The whole message is then encrypted in the second unique sessionkey (to provide data privacy), and sent to the ATM Host system.

[0068] A “Network Security Processor (NSP)” interface 132 can be used torekey an NSP 134 over a network using the “Remote Rekey” process definedabove for ATM System interface 128. NSP 134 can also be keyed manuallyusing impact printer interface 124. NSP interface 132 can be used toobtain the cryptographic status of NSP 134 in support of networkmanagement.

[0069] An “Other Commercial Crypto Devices” interface 136 represents amodular system structure (e.g., an application program interface (API))that allows new device interfaces to be defined at a later date andinstalled into the system without having to re-compile IKMS software102. It is anticipated that new equipment types will be added as thesystem matures. Interface 136 can also be used to obtain thecryptographic status of the “other” commercial cryptographic devices138, such as a link encryptor, in support of network management.

[0070] A “Browser” interface 140 can provide an access interface forhome banking clients. It is known that emerging home banking systemstend to use the Internet to provide a communications channel between ahome banking client (e.g., a customer) and a home banking server (e.g.,the bank). Browser interface 140 can support transaction privacy throughthe use of an SSL. Preferably, browser interface 140 supports theloading of certificates into browsers 142 that are owned by home bankingcustomers. “NETSCAPE COMMUNICATOR” and “MICROSOFT INTERNET EXPLORER”browsers are supported in a preferred embodiment.

[0071] A “Home Banking Client Application” interface 144 supports keyingneeds of home banking clients 146 that utilize non-browser interfaces.Several existing products support dial-up connections, use cryptographyto protect the privacy of the interaction, and employ a user ID/passwordaccess mechanism. Interface 144 supports the initial distribution of keymaterial to support the cryptographic functions within these products.

[0072] An “Accelerator Card” interface 148 supports the distribution ofpublic/private key pairs to accelerator cards 150 residing in a homebanking server farm, for example. Emerging home banking systems areknown to be implementing cryptographic acceleration in order to supportclient privacy rights. It is expected that this will require the use ofmultiple accelerator cards 150 within a server farm. These cards must beconfigured with the same public and private components so that a clientcan operate with the first available server. Interface 148 can also beused to obtain the cryptographic status of accelerator cards 150 insupport of network management.

[0073] A “Directory” interface 152 is a network interface that supportsthe directory access protocol (DAP) or lightweight DAP (LDAP). Interface152 allows an IKMS public key management module (which is part of theIKMS software) to provide certificate information to a directory 154when new certificates are created, modified, renewed, or deleted.Directory interface 152 can also support query functions to viewcontents of directory 154.

[0074] An “Organizational Certificate Authority” interface 156 allowsthe IKMS to interoperate with an existing organization's certificateauthority 158. The certificate authority is authorized by theorganization to create and sign certificates. Interface 156 can providea common entry point for an organization's key management functions.Preferably, operator 106 can use the IKMS to navigate to theorganization's certificate authority 158. IKMS can also manage when acertificate should be renewed by sending a message to certificateauthority 158 via interface 156 to instruct it to renew the certificate.

[0075] A “printer” interface 160 supports printing of system reports ata printer 162.

[0076] A “tape archive” interface 112 supports system backup and archiveof expired key material. Typically, key material has a “lifeexpectancy,” i.e., it is used for only a limited duration. Preferably,operator 106 establishes a backup policy to minimize the effects ofsystem crashes or other disasters. For example, the entire IKMS softwareimage can be stored to tape 114 to minimize recovery time. Also, sincekey and certificate material expire periodically, it is desirable toarchive this material in a secure form so that it can be recovered at alater time if necessary.

[0077] A “telephone” interface 164 allows the IKMS to accept directionfrom an authorized user via a telephone 166 for the purpose ofidentifying an equipment to be keyed from key parts. The telephone useridentifies the equipment and key parts to be used in that equipmentthrough a series of voice prompts and associated numeric responses viathe telephone key pad.

[0078] IKMS utilizes a unique work flow wherein key material can bemanaged based on its association with a particular secure communicationslink (ie., a cryptographic link). Typically, key material has aone-to-one association with a cryptographic link, although two or morecryptographic devices can participate on a single cryptographic link.The system can also support the ability to manage key material based onthe equipment. Both types of management are desirable during the lifecycle management of key material. For example, when setting up acryptographic network for the first time, the cryptographic link viewmight be most important. The network planner often wants to define acryptographic link, and then assign equipment to that link. Once thelink has been established, it may be necessary to replace a piece ofequipment in the link. In this case, it is often better to view themanagement activities from the viewpoint of the equipment. In someinstances, a cryptographic device can participate in multiplecryptographic links. For example, an ATM Host typically communicateswith a plurality of ATMs. By viewing the management process at theequipment level, key material associated with a plurality ofcryptographic links can be replaced with one operator action.

[0079] FIGS. 4A-4D provide a workflow diagram for a key managementsystem according to the present invention. FIG. 4A depicts the workflownecessary to initialize a system of cryptographic equipment and managekeys associated with that equipment. This workflow method allows anoperator to manage the keys associated with the registered equipment andcryptographic links through multiple views (from an equipment view orfrom a cryptographic link view). The ability to manage key material frommultiple views is a unique advantage of the present invention.

[0080] The workflow begins at step 1 when two legitimate operators logon to the system. A “legitimate” operator is an operator that isregistered and authorized by the organization. It is preferred that twooperators are required to log on to ensure that no single individual hasaccess to keying services or physical key material. If the IKMS has notbeen configured, the operator can first register the local account atstep 2. Registration of the local account can include assigning theaccount a name, an ID, a point-of-contact (e.g., address, phone number,e-mail address), an account status (e.g., available, not available), anaccount type (e.g., remote, local), and account capabilities (e.g.,backup account, certificate authority account, signer account). Theoperator initializes a cryptographic processor engine (CPE) at step 3,and then loads an initialization key into the CPE.

[0081] Once the local account is registered and the CPE is initialized,the system can create a public/private key pair, at step 4, that can beused to transmit messages between IKMS accounts securely. Preferably, ifthe account is a “signer” account, then the public key pair isself-signed. If it is a “non-signer” account, then the public key issent to the signer account (e.g, when it is registered) for signing.Once signed, the signed data is returned, verified, and stored by theaccount. This ensures that all certificates used in a network of IKMS'can be authenticated based on a master root certificate held at the“signer” IKMS account.

[0082] Preferably, the IKMS implements an archive service thatestablishes how generated and imported key material is archived securelyfor later retrieval by authorized personnel. Also, IKMS preferablysupports a key printer located on a local port. The port could beregistered by the operator or defaulted by the IKMS software.Preferably, the key printer is an impact printer that is used to printkey components on PIN mailers. Preferably, for security reasons, the keyprinter should be managed locally rather than being networked.

[0083] Other accounts can be registered at step 19 (see FIG. 4C). Thisprocess is similar to the registration of the local account. Preferably,all accounts with which the local account will communicate areregistered. For security reasons, messages associated with keymanagement are not sent to non-registered accounts.

[0084] Equipment types can be registered at step 5. This process definesthe common attributes of a type of equipment. For example, attributessuch as the name, manufacturer, and model number can be defined.Similarly, the number of cryptographic links of which the equipment cansimultaneously be a part, type of unique key (i.e., a key that is uniqueto a particular equipment), cryptoperiod of the unique key, type ofalgorithms supported, type of initial key(s) (i.e., key shared betweenequipments that is used to start up communications processing), and typeof periodic net key (i.e., operational key shared between equipments,typically replaces initial key during operations) can be defined. Theallowable distribution method for the unique key, the initial key(s),and the net key(s) can also be defined. These attributes describe thetype of equipment and are registered once. This helps to simplify thesubsequent registration of instances of this type, and requires that thecomplicated aspects of the equipment be registered only once.

[0085] Once equipment types have been registered, specific instances ofan equipment type can be registered at step 6. For each equipmentinstance, a serial number is entered, a net algorithm is selected, andspecific distribution methods for the unique key, initial key(s), andthe net key(s) are selected.

[0086] Finally, an association between equipment and the cryptographiclink is made at step 7 by “registering a service.” Here, the name of thesecure communications service is entered (and validated for uniqueness),and an “in-service date” is selected (i.e., a date on which the serviceis to begin). Equipment instances are then selected from the set ofregistered equipment. Upon selection of the first equipment, onlyequipment with compatible registered algorithm types may be selected.For each selected equipment, the operator must specify the source ofeach registered key type (unique, initial, and net). The source can be“generated” (by IKMS), it can be “imported” from another system, or itcan come from key components. The cryptoperiod for each key is alsodefined. This determines how long the key should be used and triggers anautomated rekey process when the cryptoperiod expires. Completion of theprocess defined in FIG. 4A configures the system and establishescryptographic link services.

[0087] The operator can now use the process defined in FIGS. 4B-4C tomaintain the system. An “Import Key” function 11 can be used toassociate key material from a “foreign” key management system with acryptographic link (service) defined in IKMS. The key is brought intothe system, associated with a service, and stored securely in the IKMSdatabase. A version number of the key is assigned during its import, asis its effective date.

[0088] A “Send Key” function 12 can be used to support recovery ofservice. An operator can decide to resend a key to an existing service,equipment, or account. This function allows an operator to recover fromfailures. For example, if an equipment fails it may lose its key. Oncethe equipment is repaired, it may be necessary to re-install the “old”keys. This can be accomplished by using the “Send Key” function.

[0089] A “Reconcile Key” function 13 can be used to validate that a keysent to another account was received by that account. This validationoccurs by reconciling the receipt sent from the receiving account to thesending account with the internal accounting records at the sendingaccount. Typically reconciliation occurs automatically. However, it maybe necessary to perform the reconciliation manually to account fore-mail failures.

[0090] “Send and Receive Mail” functions 26 allow an IKMS operator toview and send mail. This allows the operator to communicate with otherIKMS accounts or other e-mail locations to coordinate activitiesassociated with key management. An example would be to trace a key sentfrom one account to another that had not been reconciled within theexpected period of time. An e-mail could be sent to the account askingif the key had been received.

[0091] A “Remove Key” function 17 allows the operator to coordinate thearchive of key that has expired or been superceded. This key isencrypted in an archive key and stored for a period, preferably of up to10 years. The key can be recovered using the “Restore Key” function 17.The restore function brings in an archive record, and translates the keyfor distribution to an an equipment such as an “analysis station” (i.e.,a processor that accepts the key and, therefrom, decrypts one or moreparticular transactions (e.g., for law enforcement purposes)). In thisway, the key is delivered securely to the “analysis station”.

[0092] An “Add/Modify/Delete Account” function 19 allows the operator toadd new IKMS accounts, delete accounts no longer needed, or modifyattributes of existing accounts.

[0093] An “Add/Modify/Delete Equipment Type” function 20 allows theoperator to add new equipment types, delete equipment types that have noassigned instances of equipment, or modify attributes associated withexisting equipment types.

[0094] An “Add/Modify/Delete Equipment” function 22 allows the operatorto add new equipment instances, delete equipment instances that are notcurrently assigned to a service, or modify attributes associated with anequipment instance.

[0095] An “Add/Modify/Delete Service” function 23 allows the operator todefine new services (i.e., cryptographic link associations), deleteexisting services, or modify attributes associated with existingservices.

[0096] A “Supercede Key” function 21 allows the operator to select aservice (cryptographic link association) and specify that a supercedingversion of the key should be sent to all equipment associated with thatservice. This function can be used to combat a current or potentialcompromise by advancing to a new key for the network.

[0097] A “Changeover CPE” function 24 is used to translate the encryptedkey database from the current storage (or protection) key to a newstorage key. Preferably, the key material has a finite usefullife—including keys used to protect other keys. This function allows theoperator to change this storage key.

[0098] A “Init/Restore CPE” function 25 allows an operator to recoverfrom CPE equipment failure. This function supports the replacement ofthe failed equipment and then subsequently allows the initialization keymaterial to be reloaded into the new CPE hardware. This allows the userto recover the encrypted key database in a secure manner.

[0099] A “View Scheduler” function 27 provides information that givesthe operator an overall sense of the status of the system. This functionprovides an indication of the current processing load, alerts aboutrequired operator actions, and notices of system or equipment failures.

[0100] A “View Key Inventory” function 28 allows the operator to viewthe current key material inventory held by the IKMS account. Preferably,the operator can view or print this inventory.

[0101] A “View Equipment Inventory” function 29 allows the operator toview the current equipment registered with this account. Preferably, theoperator can view or print the equipment inventory.

[0102] A “View Distribution Summary” function 30 allows the operator toview the status of all key distributions of key material held ininventory. The date of delivery, the operators logged on when thedelivery occurred, the version and name of the key delivered, and therecipient of the delivery are listed by this function. The operator canview or print the distribution summary.

[0103] A “View Node Connectivity” function 34 allows the operator toview the connectivity of the equipment defined in the Register Servicefunction (FIG. 4A at step 7). The equipment instances are organized byservice name and key version number. Preferably, the operator can viewor print the node connectivity.

[0104] A “View CPE Status” function 33 allows the operator to view thestatus of the CPE card. The card's firmware image id, card state, cardserial number, status of loaded application keys, status of archive keycheck, and the status of a cryptographic check are displayed.

[0105] A “View Errors” function 15 allows the operator to view detailsregarding any errors encountered during IKMS processing. This allows theoperator to identify problems and correct them promptly.

[0106] A “View Suspended Jobs” function 16 allows the operator to viewany scheduled IKMS function (such as a key generation or keydistribution) which has been suspended due to a lack of information orunavailability of the device. Once the information is available or thedevice becomes available, the suspended job is retried.

[0107] A “View Equipment Out of Service” function 31 allows the operatorto view any equipment that is not communicating properly with IKMS. Ifcommunications to an equipment fails, the equipment is placed on thislist and subsequent distributions to that equipment are suspended. Thisprevents sending unnecessary messages to an equipment that is known tobe non-functional. Once the equipment is made functional, the equipmentis removed from the list and distributions will resume.

[0108] A “Test Print” function 32 allows the operator to temporarilysuspend jobs in the print queue to load new PIN mailer forms on theprinter. This function allows the operator to print a test pattern onthe form to ensure that it is properly aligned. Once the form isaligned, the Test Print function 32 is cancelled and printing to the keyprinter resumes.

[0109] An “Archive Report 18 function allows the operator to view andprint a report on all key material that has been archived.

[0110] “Request Send Components” and “Request Associate Components”functions 14 are provided to support the distribution of additional keyparts (components) to a key custodian and to support the association ofselected key parts to form keys in end cryptographic devices. A keycustodian will load key parts into an equipment and then call back toIKMS where the IKMS operator will use the “Request Associate Components”function 14 to select the identified key parts. These key parts are thencombined by IKMS into a key that is distributed to all the otherequipment related to the equipment being physically loaded (from the keyparts) by the key custodian.

[0111]FIG. 5 shows the functional organization of a softwarearchitecture for a preferred embodiment of the present invention. Themain software units are a database 504. human machine interface (HMI)502, and a background module 506 that handles all of the HMI-requestedand scheduled tasks. Preferably, database 504 is an “ORACLE” databaseand the preferred software implementation includes Microsoft's VisualC++ (or any C++ development) and the Oracle PL/SQL language.

[0112] Database 504 stores all of the IKMS's data. This is a relationaldatabase that contains the schema for the IKMS application. The databaseschema has tables that are used to store the following information:operator-entered information, IKMS generated data that must remain inthe system, data that needs to be passed between program units,initialization parameters, options on various windows that areselectable by the operator, look-up tables that are used to translateenumerated values into character strings that are readable by theoperator, and jobs that must be processed by the IKMS. The jobs that areprocessed by the IKMS are HMIentered requests and periodic tasks basedon scheduled events. The HMI-entered tasks have a higher priority andwill be fetched for execution prior to scheduled tasks. IKMS uses an“ORACLE” internal job queue 508 that allows tasks to be executed on aperiodic basis defined by the application. Primary access to database504 by the application is through an open database connectivity (ODBC)interface in the C++ environment that invokes PL/SQL stored procedures.

[0113] HFMI 502 handles the operator interface. That is, HMI 502 allowsthe operator to view/enter IKMS information. HMI 502 also has aninterface to database 504 for storage and retrieval. Any informationdisplayed to the operator is fetched from database 504 and anypersistent information or tasks requested by the operator are stored indatabase 504. HMI 502 has several functional areas as follows:registration functions 512 to record application data, request functions514 that cause data to be sent, received or deleted from the system,cryptographic initialization and maintenance functions 514, views thatdisplay scheduled tasks 516, item inventory and status 516, and reportgeneration 516.

[0114] Background task 506 handles jobs entered via HMI 502, and jobsthat must be processed on a periodic basis. Background task 506 fetchesjobs from a set of tables in database 504. HMI-entered jobs have thehighest priority. These will be fetched first from queue 508. Othertasks are scheduled on a periodic basis. The jobs that background task506 performs include the generation of keys, printing keys to a key PINprinter 518, distributing keys over a network 520, interfacing to a CPEdevice 522, creating archive files for each key generated and auditingthe appropriate information 524. Background task 506 performs most ofthe interface functions to CPE device 522, key PIN printer 518, andnetwork 520. Reports are sent to a print queue 526 for printing on areport printer. Key material can be exchanged securely with other IKMSsystems through a mail queue 528. A floppy interface 530 is used todistribute key material and other initialization data to local devices.

[0115] Telephone Unit module 532 performs three main tasks: providestelephone prompts, accepts input from the telephone, and sends messagesto Background Task 506. Telephone Unit module 532 is used to allow anauthorized user to remotely inform IKMS which key parts (components)should be used with a particular equipment. The user is prompted byTelephone Unit module 532 to identify the equipment to be keyed and toidentify the key parts to be used in the equipment. Once thisinformation is determined, Telephone Unit module 532 sends a message toBackground Task 506 to immediately schedule the association of theidentified key parts and the subsequent distribution of the resultantkey to all other equipment related to the identified equipment. Forexample, if an ATM is identified through this process, and key parts 1and 2 are identified as the key parts for the ATM's AATM key, then theIKMS will build the ATM's AATM key from the identified key parts, andthen distribute AATM to the ATM Host associated with the ATM.

[0116]FIG. 6 shows the flow of information in the preferredimplementation for the background task 506. Background task 506 has thetask of processing all the jobs that get entered into a job queue 604. Amain background routine (BA Main) 602 creates several threads thatcontinuously read job queue 604 until a job is fetched. Once a job isfetched, it is executed until completion or until an error occurs. Anyerrors are audited and written to an error log 606 in database 608 sothe operator can view the errors. Any thread can process any type ofjob.

[0117] The various types of jobs are as follows: key generation, keydistribution via a printer 610 or network 612, and email processing 614.All security critical events are audited in an audit log 616. Thisincludes the generation, distribution, and destruction of key materialas well as the establishment of secure communications links. Each jobinterfaces to a CPE 618 for key generation, encryption, decryption, andtranslation functions. Translation is the re-encryption of key materialfrom a storage key to a distribution key or vice versa.

[0118] The Telephone Unit process 620 also submits jobs to Job queue604. These jobs cause the creation of key based on existing key parts(components). Once the key parts are associated, the resultant key isdistributed to all other equipment related to the equipment that wasmanually keyed from these key parts.

[0119]FIG. 7 shows a top level design of a human machine interface (HMI)for a preferred embodiment of the present invention. Operator initiatedactions can be selected from a top level HMI screen 30 as shown.Preferably, the HMI is designed to help the operator accomplish keymanagement tasks in an unambiguous way.

[0120] The IKMS Desktop is the main screen of the IKMS softwareapplication. Screen 30 is displayed when IKMS is started, and it can beminimized (by pressing the minimize button) or closed at any time. Ifscreen 30 is closed, the IKMS program will be terminated and allassociated IKMS screens will be closed as well. The IKMS desktop has aseries of pull down selections at the top of the screen. The operatormay choose from any of these items. The choices include File, Archive,Request, Register, CPE, View, Remote Rekey, and Help. There are multipleselections under many of these top-level selections. Each sub-selectionwill now be discussed in greater detail.

[0121] At the bottom of the IKMS desktop are a series of indicators thatprovide critical IKMS application status. Desktop indictors show whennew jobs are suspended, when a “CPE error” is detected, when a “printererror” is detected, when a “communications error” is detected, when“changeover” is in progress, and when a “background error” is detected.

[0122] The File menu contains two sub-choices: Exit and Test Print. TheExit task allows the operator to log-off the IKMS application. The TestPrinter task allows the operator suspend current print jobs and to alignPIN forms in the printer.

[0123] The Archive menu selection has two sub-choices: Restore Keys, andReport. The Restore Keys task allows the operator to restore archivedkey material for distribution to equipment. Once restored, the key isdistributed to the selected equipment, but is not retained in the localinventory. The service/key name, effective date, and key type of thedesired service uniquely identify the keying material. The ArchiveSummary Report window lists all key material that has been archived overa user-defined period.

[0124] The Request menu selection has six sub-choices: Send Key, Import,Supersession, Associate Components, Send Components, and PreliminaryCertificates.

[0125] The Request Send Key function supports a “Request Send Key toService” and a “Request Send Key to Equipment” function. The RequestSend Key to a Service function enables an operator to manually send keymaterial to a service. This allows the keys for a group of equipment tobe restored in a single operator action. The Request Sehd Key to anEquipment function enables an operator to manually send key material toa selected equipment. This allows the keys held in a piece of equipmentto be restored in a single operator action.

[0126] The Request Import Physical Key function enables an operator toimport a key from a foreign system so it can later be distributedautomatically by IKMS. Keys within services can be defined with a sourceof import.

[0127] The Request Supersession function enables an operator tosupersede keys in equipment. This function causes the current key ininventory to be deleted and a replacement to be generated if the key isassociated with a valid service (or a valid equipment if the key is anequipment unique).

[0128] The Request Associate Components function enables an operator toselect two components and associate them with a service to build an AATMor BATM key. A component is a key part. Key parts are combined throughan exclusive-OR process to form plaintext keys. IKMS supports thegeneration of components (key parts) and their subsequent distributionto a key custodian. The address or destination of the key custodian isknown as a receptacle. IKMS treats a receptacle like an equipment inthat receptacles are registered with the system. During thisregistration process, the number of components to be generated alongwith the cryptoperiod of the components are defined. Components are thendistributed to the receptacle. IKMS generates new components when acomponent is used to form a key, when components expire (and thus needto be replaced), or when the IKMS decides additional components areneeded at a receptacle (Request Send Components).

[0129] The preferred embodiment of IKMS supports association ofcomponents by IKMS operator direction and through a telephone interface(such as a voice recognition unit). The manual association of componentsoccurs through the Request Associate Components function, while theautomated association occurs through the telephone interface. Whenassociating components through the telephone interface, a user dialsinto the IKMS telephone interface and is prompted to identifyhim/herself.

[0130] Once successful user verification is made, the user is promptedto identify the equipment being keyed from components. Once theequipment is identified, the user is prompted to identify the keycomponents to be associated with each key required by the identifiedequipment. For example, if the equipment is an ATM and requires an AATMkey, the user will be required to enter the numeric identifierassociated with both key parts. Once identified, the IKMS system willverify that the components exist in the database, combine thosecomponents, and send the resultant key to any other equipment associatedwith the service of which the ATM is part. Once components are used,they are deleted by IKMS and are no longer available for association infuture requests.

[0131] The Request Send Components function enables an operator tomanual send additional components to a Receptacle. This allows anadditional number of components to be generated and sent without havingto re-define the number of components distributed periodically to theReceptacle.

[0132] The Request Preliminary Certificates function enables an operatorto create a userdefined number of unique preliminary devicecertificates. These certificates are used to initialize remote rekeycapable equipment so that they can be securely keyed (from cold start)over open networks. The preliminary certificates are created and aresent to the operator identified factory loader system. Factory loadersystems are registered as part of the Registration function describedbelow.

[0133] The Register menu selection has five sub-choices: Service,Equipment, Equipment Type, Account, and Factory Loader.

[0134] The Equipment Type screens allow an operator to create a newequipment type, to select and modify an existing equipment type, or todelete an existing equipment type. The Add or Modify Equipment Typescreen allows an operator to establish fundamental characteristics for aspecific type of equipment. These parameters are common to all equipmentof the type being defined (added) or modified. A type is uniquelydefined by the combination of equipment type name, manufacturer, andmodel number.

[0135] The Register Equipment screen allows an operator to define,modify, and delete specific instances of a type of equipment. Theoperator can also use this function to change attributes of registeredequipment. The Add or Modify Equipment screen allows operators to selector enter specific characteristics for specific equipment including thetype of keys used by the equipment, its algorithm and its keydistribution method.

[0136] The Register Service screen allows an operator to register ormodify services defined within an IKMS account. A service is anassociation between one or more equipment and key material sharedbetween that equipment. It can be thought of as a secure communicationslink. A service defines a set of equipment, the key material that isshared between that equipment, when the key material should be in use,and when the key material should be replaced.

[0137] The Register Account function allows the operators to registerand modify the local IKMS account data. The local account informationcannot be deleted. This function is also used to add, modify, and deleteinformation about other accounts. The preferred embodiment uses theregistration of other accounts to support distribution of key materialbetween IKMS accounts.

[0138] The Register Factory Loader screen allows an operator to create,register and modify information regarding factory loader systems used toinitialize remote rekey capable equipment at the manufacturer's site. Itis necessary to register these loader systems so that messagescontaining files of preliminary device certificates (created by theRequest Preliminary Certificate function) can be sent to the remoterekey capable device manufacturer where they (the certificates) can beloaded into the device. The preliminary certificates are used by IKMS toauthenticate the device during its “cold start” and then to develop asecure session for loading the final unique device certificate.

[0139] The CPE menu selection has three sub-choices: Changeover,Init/Restore, and Status. The Cryptographic Processor Engine (CPE)Changeover is responsible for changing from one storage key to the nextstorage key. The storage key encrypts all keys stored by IKMS ensuringthat all keys are stored securely. Before Changeover can be started, thenext storage key must be loaded.

[0140] The CPE/Initialization/Restore storage key function is used toinitialize the currently installed CPE card. It is used when a card hasbeen installed for the first time, to reinstall a card when an error orother problem is determined, and to install a new card when the currentcard has failed. The CPE Status function is used to test the currentlyinstalled CPE card, and to retrieve information identifying thecurrently installed card.

[0141] The View menu selection has eight sub-choices: Scheduler, Errors,Suspended Jobs, Equipment Out of Service, Key Inventory, EquipmentInventory, Distribution Summary, and Network Connectivity.

[0142] The View Scheduler function allows the operator to graphicallysee the key material distributions and imports that are scheduled forthe next seven days beginning with today. It also allows the operator toview the percent complete of any ongoing Changeover and the percent fullof the Audit Log. These functions are selected from the desktop byselecting View→Scheduler. When invoked, a multi-tab window appears. Onetab shows the pending distributions, one tab shows the pending imports,and the last tab shows the status of Changeover and the Audit Log.

[0143] The View Errors function allows an operator to list (ie., view)current IKMS application errors.

[0144] The View Suspended Jobs function allows an operator to list(i.e., view) IKMS jobs that are suspended. Jobs are IKMS activities thatare automatically scheduled to occur based on a registered service orother operator initiated activity.

[0145] If the system detects an application level negativeacknowledgement or time out while performing an Electronic SymmetricDistribution, the Distribution History status for the message is changedto “failed”. When this occurs, the operator is notified (via a pop-upwindow) that a key package was not acknowledged and the “ReceivingEquipment Out of Service” indicator is set on the Main Desktop. Theequipment that is taken out-of-service is placed on the Equipment Out ofService list (which can be viewed by selecting View Equipment Out ofService). IKMS will not attempt to distribute key material to anyequipment on this list. All key distribution jobs associated with anequipment that is out-of-service are suspended and will be retried whenthe equipment is successfully fixed and thus removed from the EquipmentOut of Service list.

[0146] The View Key Inventory function allows an operator to list (ie.,view) all key material held securely in the IKMS database. The View KeyDistribution History window, accessed from the View Key Inventorywindow, allows an operator to see the distribution history of theselected key name and key type. All versions associated with theselected key name and key type are displayed in this list.

[0147] The View Equipment Inventory function allows an operator to list(i.e., view) all equipment registered in the IKMS database.

[0148] The View Distribution Summary function allows an operator to seethe distribution history of all key material over a selected time frame.

[0149] The View Network Connectivity function lists the communicationrelationship (the services) defined within IKMS and shows the type ofcryptographic protection provided by this communication relationship(i.e., the keys and algorithms).

[0150] The Remote Rekey menu selection has one choice: DeviceInitialization. Once a device has been initialized at its factory, it isshipped to site and then further initialized by IKMS. DeviceInitialization uses the preliminary device certificate to mutuallyauthenticate with the device and then to develop a secure data channelfor the distribution of a newly generated unique device certificate. TheIKMS ensures that each preliminary certificate is used only once (by anydevice). Device Initialization allows the replacement of the preliminarycertificate or the renewal of the existing device certificate. Remoterekeying is described in greater detail below.

[0151] The Help menu selection has two main sub-choices: Help Topics andAbout IKMS. Help Topics displays the Table of Contents, Keyword Indexlist, and the Database Search. The question mark button on the toolbaralso presents the Help Topics window. Help Topics also shows thecopyright notice and version of IKMS. The Toolbar's Context Help button(the arrow and question mark button) allows an operator to double clickin an IKMS window (such as another Toolbar button or pull-down menuitem) and receive help information on the use of that menu item orbutton. The Help topic will be shown for the item selected.

[0152] At the bottom of the IKMS desktop is a status bar withinformational indicators that provide critical status on the state ofthe IKMS application. Indicators in the status bar include: Suspendedjobs indicator, CPE error indicator, Printer error indicator,Communications error indicator, Changeover in process indicator, andBackground error indicator.

[0153] When the CPE Error indicator (shown by the “CPE ERR”) orCommunications Error indicator (shown as “COMMS”) is activated, they arereset, preferably, only through their next successful use. IKMScontinues to attempt processing each function when it has failed. Nooperator intervention is required to reset these indicators.

[0154] The Suspended job indicator can be acknowledged through theSuspended Jobs window. The Printer Error indicator refers to a problemwith a printer, and solving the printing problem resets the PrinterError Indicator. The Changeover In Process indicator lets the operatorknow that changeover is currently proceeding.

[0155] The ‘Clear Status’ buttons located on the View Detail windowassociated with the desktop indicator clear the status indicators on thedesktop so that new errors or suspended jobs can cause the indicator tore-activate. Preferably, these buttons have no effect on the actualerrors or suspended job status.

[0156] The Receiving Equipment Out of Service (OOS) indicator shows theoperator when equipment has been placed out of service because ofcommunications failure or timeout. The equipment placed out of servicecan be viewed in the View>Receiving Equipment Out of Service screen.Pressing the ‘Clear OOS’ button resets this indicator.

[0157] A preferred embodiment of the present invention has been designedin “WINDOWS NT” using “VISUAL C++.” It should be understood that a“WINDOWS” application can be designed to be “modeless,” i.e., to allowthe operator to invoke windows from different functions simultaneously.For example, if the operator were registering a cryptographic link(e.g., a service), and discovered that the equipment to be included inthe service was not registered, the operator could call the “registerequipment” function and register the equipment without closing the“register service” window. Messages can then be passed between the openwindows to ensure each affected window is updated properly.

[0158] Preferably, IKMS executes processes that can be initiated eithermanually or automatically. Manually initiated processes can be invokedthrough the operator's use of the HMI described above. Automaticprocesses can include scheduled replacement of key material (which canbe set up by the operator when the equipment and cryptographic networkare defined), and requests for remote rekey from remote devices. Theautomated tasks of scheduling and remote rekey are described in detailbelow.

[0159] Automated Scheduling

[0160] In an automated scheduling method according to the presentinvention, an operator first defines equipment types and equipmentinstances, and then associates equipment with cryptographic links (ornetworks). To build the cryptographic link association, the operatorfirst selects equipment to be associated, and then selects the numberand type of key or keys that must be delivered to the equipment in thislink. The operator then establishes how the assigned keys are created(e.g., generated by IKMS or imported from a “foreign” system), anddefines the cryptoperiod of each key. The cryptoperiod defines the“life” of the key, i.e., for how long a delivered key may be used.

[0161] The scheduling function monitors the cryptoperiod for the key ondefined cryptographic links, and automatically schedules the delivery ofnew key to these links when the cryptoperiod expires. The system alwaysdelivers the key slightly in advance of its need date (or time). Thedelivery time is based on the time associated with the delivery methodcoupled with the cryptoperiod of the key. For example, if the deliverymethod is “physical” then at least one day could be needed to generatethe physical key and have it sent to the equipment via a one daydelivery service. If the method were remote rekey, the network can beused to send the key minutes before it expires.

[0162]FIG. 8 is a flowchart of an automated key generation anddistribution process 640 according to the present invention. Before keysare generated and distributed, the equipment to receive the distributionmust be registered in the system and associated with a securecommunications service. The secure communications service establishesthe communication link or network that the user wants to protect throughcryptography. The key material generated for this service enables thecryptography to protect the link. Classes of equipment are registeredwith the system at step 642. In this step the general characteristics ofthe equipment class are defined. This includes the type of equipment,the number of services it can participate in, the types of keys that canbe distributed to the equipment, and the types of distribution methodssupported by the equipment. Once the equipment classes are defined,specific instances of the equipment are registered at step 644. Here thespecific network cryptographic algorithm is selected as well as thespecific key types to be distributed and the specific distributionmethod.

[0163] After defining specific equipment, the equipment is grouped intosecure communication services at step 646. Here the operator is definingthe secure communication links between selected equipment. Equipmentthat is to communicate securely is selected, as well as the types ofsecure links this equipment will share. Each secure communication linkis protected by a key. Thus there is a one to one relationship betweensecure communication links and keys. For each defined link (key), thetype of key and its cryptoperiod are defined as well as it generationsource. The system allows keys to be generated by IKMS, to be importedfrom other key management systems, or to be created from key parts thatare already in the field.

[0164] Once the secure communications links are defined (at step 646)the system creates a distribution schedule at step 648, and processesthe schedule at step 650. This is based on the cryptoperiod of thematerial, the lead time associated with the distribution method, and thein-service date entered when the secure communication link was created.For example, if today is Sep. 28, 1990 and a secure communicationsservice is defined to begin on Oct. 1/, 1990 then the system schedulesthe creation and distribution of that key automatically to support thephysical parameters associated with the registered equipment in thesecure communications service. If the equipment gets key deliveredphysically, then it must be created before its need date to allow timefor mailing. In this case the key would be created 2 days ahead of timeto allow the key to be sent by overnight mail so that it will be at theequipment for use by Oct. 1, 1990. The generation process occurs in step652.

[0165] Once a key is generated, it is securely stored, at step 654, in alocal database encrypted under a protection key. The key is thendistributed, at step 656, to each equipment associated with the securecommunication service based on the distribution method and the lead timeassociated with that distribution method. If problems arise and the keycan not be delivered to all equipment in the secure communicationservice, then the system keeps track of this and allows the distributionto be re-tried once the problem is corrected (step 658). Eachdistribution is recorded, at step 660, so that a record of alldistributions is available. This distribution record includes what wasdistributed, who initiated the distribution, when the distributionoccurred and the status of the distribution (success or failure). Atstep 662, the scheduler process automatically tracks distribution basedon the cryptoperiod of key material and will schedule the generation anddistribution of replacement key based on the key's cryptoperiod.

[0166] Remote Rekeying

[0167] IKMS also supports secure remote rekey of cryptographic devicesvia public or private networks. Remote rekey support is provided by arekey method and secure communications protocol that support the secure,authenticated distribution of key material to cryptographic equipmentsuch as ATMs, NSPs, and Financial Switches (FS), via the networkconnection to that element. Remote rekey involves three stages:preliminary initialization, device initialization, and net operation.IKMS participates and supports the first stage (preliminaryinitialization) but, in a preferred embodiment, does not directly loadthe preliminary certificate into the device. Preferably, the loading ofthe preliminary certificate is performed by a certificate loader at thefactory site. The certificate loader can be a PC. The IKMS directlyperforms the last two stages of the rekey process (device initializationand net operations). During the rekey stages, the cryptographic device(or secure device) is taken through a series of states that includeloading remote rekey initialization data to secure delivery ofoperational key material.

[0168] Preliminary initialization supports secure authentication of thedevice initialization process. Preferably, preliminary initialization isperformed at a physically secure facility within the factory.Preliminary initialization can occur in the field, but this is lesssecure. The security device is connected to a local network and receivesits preliminary certificate from the Factory Certificate Loader over thenetwork. Standard network protocols (e.g., TCP/IP) can be used totransport the messages. Network protocols specific to a security device(e.g., ISO-8583) can also be used. The security device is provided withits preliminary certificate, which it stores. The certificate allows thedevice to prove its identity to another device that has the same IKMSauthentication parameters (i.e., a certificate signature based on thesame IKMS root certificate).

[0169] Device initialization involves creating a new unique devicecertificate, and then securely loading that certificate (both public andprivate parts) into the device using the preliminary certificate in thedevice. Since the loading process is secure, device initialization canbe performed over open networks, and thus, can be performed remotely.IKMS ensures that each preliminary certificate is only used once by anydevice. Once the new device certificate is loaded, the old preliminarycertificate is destroyed. Attributes in the preliminary certificateprevent their use with other preliminary certificates to perform securecommunications. The preliminary certificate is only used to provide asecure authentication channel for the receipt of the device certificate.

[0170] Device initialization can be performed using open networks andstandard protocols, including service network specific protocols such asX9.2. This is possible because the preliminary certificate is used tocreate a secure channel between the IKMS and the security device. Afterthe secure connection is established and authenticated, the IKMS accountdistributes a device specific certificate and user specificauthentication parameters to the security device. The security devicepermanently stores the device certificate and authentication parameters.These data are used for future key distribution activities.

[0171] During net operation, the IKMS account uses the devicecertificate and authentication data to establish a secure, authenticatedlink to the security device over the communications path used for normaloperations. This communications path includes all transport protocolsused by the network. After the link is established, the IKMS accountdistributes the keys necessary to activate the specific cryptographiclink. Key material is securely and automatically sent to each equipmentin the link. If the key is periodically replaced, the IKMS accountperiodically establishes the secure, authenticated link, and providesthe periodically changed key. A secure session can be established viathe remote rekey protocol (as appropriate) for each equipment assignedto the cryptographic link.

[0172] Remote Rekey Life Cycle Process

[0173] The ability to rekey a device remotely over public networks (orany unsecured network) requires a key management process that ismanageable with the cryptographic strength necessary to withstandattacks on the public network. The ultimate goal of any automated remoterekey process is to provide a keying capability that simplifies the keymanagement process while improving the security of the managementprocess. The development of Integrated Key Management System (IKMS) andits associated Remote Rekey protocol accomplish these goals. The processof key management is automated and simplified by allowing systemmanagers to initiate keying activities over networks remotely withouthaving to send two-person teams to an equipment site. The overallsecurity of the process is improved through the use of strongpublic/private cryptographic and authentication mechanisms coupled withextensive audit collection capabilities and operational controls.

[0174]FIG. 9 shows the connectivity of a remote rekey system. APreliminary Certificate Loader 902 is located at the manufacturer and isused to perform the preliminary initialization function. This system(902) manages the preliminary initialization of a device in a secureenvironment. Once initialized, the device 904 is shipped to itsoperational location and placed in service where all subsequent keyingoperations can occur over open networks. IKMS 900 supports thepreliminary initialization process by providing a message or filecontaining the preliminary device certificates. IKMS 900 generates somenumber of certificates based on the manufacturer need. This file/messagecontains both the public and private components of the certificate andmust be protected. Since the preliminary certificate is only used tosecurely load the actual device 904 certificate and since thepreliminary certificate can only be used once, its loss or compromise ismanageable with limited security risk.

[0175] The Preliminary Initialization process consists of loading adevice 904 with with a preliminary certificate thus providing device 904with an authenticatable identity. The Preliminary Certificate Loader 902provides a signed preliminary certificate to device 904. Thiscertificate provides a means to authenticate the identity of the device.Preliminary Certificate Loader 902 is used during the manufacturingprocess to load devices with the key material necessary to supportsecure key delivery to the devices once they are fielded at a customersite.

[0176] Preliminary Certificate Loader 902 receives all of itspreliminary certificates from IKMS 900. Preliminary Certificate Loader902 does not require cryptographic gear to load the certificates,however, it may be prudent to protect the distribution of preliminarycertificates between Preliminary Certificate Loader 902 and IKMS 900using cryptography or physical security. Upon loading a preliminarycertificate, Preliminary Certificate Loader 902 sends a message to IKMS900 informing it which device 904 was loaded and which preliminarycertificate was used. This information is recorded with the Equipment'sregistration (in IKMS 900) and is subsequently used to ensure that onlythis equipment can be “converted” using the loaded preliminarycertificate. Once device 904 has completed the preliminaryinitialization, device 904 is shipped to its operational site. Oncethere, IKMS 900 can be used to complete the device initialization andnetwork operations stages of the remote rekey protocol.

[0177] IKMS 900 is used to device initialize device 904 once device 904has been shipped to the organization's operational site. IKMS 900communicates with device 904 over open networks, and exchangescertificate information. Device 904 provides its preliminary publiccertificate, while IKMS 900 provides its device public certificate. IKMS900 verifies the identity of device 904 using the preliminarycertificate. Verification ensures that this is the first time thepreliminary certificate has been used, and that the device's identifiermatches the preliminary certificate. This information was returned byPreliminary Certificate Loader 902 to IKMS 900 during the preliminaryinitialization phase.

[0178] Once device 904 has been authenticated, IKMS 900 and device 904develop a secure channel using key exchange algorithm parameters passedduring the certificate exchange. Preferably, the key exchange algorithmis Diffie-Hellman, and the algorithm will be 2 or 3 key triple-DES inthe CBC or ECB mode. A preferred embodiment of IKMS supports multiplekey exchange algorithms, and multiple encryption algorithm/modes. Theactual algorithm used is based on the security need determined at thetime of use.

[0179] IKMS 900 then generates and sends a device public certificate(both public and private parts) to device 904. The device publiccertificate is protected in the secure communication channel developedbetween IKMS 900 and device 904. Two layers of protection are used. Thechannel is protected by encryption while the public/private key pair isprotected by another layer of encryption. The Key Exchange Algorithmprocess provides the keys necessary to implement both layers ofencryption. Once device 904 receives the new certificate, it replacesits preliminary certificate with the new one. Preferably, the oldpreliminary certificate is never used again. IKMS tracks this to ensureit will never be used again.

[0180] Device 904 is now ready for remote rekey use, and can now beplaced into a key distribution service. A service defines therelationship between registered equipment and their associatedalgorithms and types of key material. The registration of a servicedefines what key (including algorithm and type) should be created foreach link, what equipment participate on a link, and how long the keyshould exist on a link before creating a new key.

[0181] Equipment associated with a service has a defined distributionmethod. Preferably, the distribution method is remote rekey. Othermethods include physical (i.e., split knowledge) delivery, or electronicsymmetric delivery. The most secure delivery method is remote rekey.IKMS 900 supports multiple distribution methods, as the remote rekeyfunction typically will not be implemented in equipment instantaneously.Consequently, IKMS handles legacy distribution methods as well as newones. The preferred distribution method to device 904 is the remoterekey method. Once placed in a service, key distributions areautomatically scheduled and will occur using the remote rekey process.The following sections describe in detail how the IKMS implements eachphase of the remote rekey process (from initialization to key delivery).The entire remote rekey initialization and key delivery process isdepicted in FIG. 10.

[0182] The rekey initialization process begins at step 501 with thecreation of preliminary public/private key pairs at the IKMS. The IKMSthen sends, at step 502, a message or file containing the preliminarypublic/private key pairs to the Factory Loader. The Factory Loaderreceives the preliminary public/private key pairs at step 503. Theoperator or a factory inventory system registers the newly manufactureddevice with the Factory Loader at step 504. A preliminary public/privatekey pair is selected and loaded into the device at step 505. At step506, the loading process automatically sends a message to IKMS informingIKMS which device (or devices) have been loaded, and which preliminarypublic/private key pair(s) are associated with that equipment. IKMSreceives this notification, at step 507, and automatically registers thedevice in its database. The IKMS may be required to augment thisregistration to include additional information such as the networkaddress of the device at it final location.

[0183] The device is shipped from the factory to a designated customersite at step 508. Once the device is at the appropriate site andproperly configured for its operational network, device initializationis started at step 509. During step 509, the preliminary public/privatekey pair is replaced with a device public/private key pair. IKMS createsthis key pair and sends it to the device using the protocol describedbelow with reference to FIG. 13. Once the device is fully initialized itis ready to participate in a remote rekey service.

[0184] The IKMS operator registers the device in an appropriate serviceat step 510. Once registered, IKMS automatically distributes theappropriate operational key material to the device, at step 511, usingthe key distribution method defined for the device (remote rekey in thiscase).

[0185]FIG. 11 shows the sequence of operator steps that are conducted atthe Factory Loader and the IKMS to initiate a full remote rekeyinitialization. These operator steps are used to implement the processflow described in FIG. 10.

[0186] Preliminary Initialization Process

[0187] The Preliminary Initialization process loads the device with apreliminary certificate signed by IKMS and the associated private value.The device must be manufactured with a key exchange capability thatmatches the type of preliminary certificate (and subsequently devicecertificate) loaded into the device. The operator activities required atthe Factory Loader and the IKMS to accomplish Preliminary Initializationare shown in FIG. 11 and described in detail below.

[0188] The Preliminary Initialization process begins at step 521 withthe operator coordinated registration of the IKMS at the Factory Loader,and at step 527 with the registration of the Factory Loader at the IKMS.The registration of the Factory Loader and IKMS configure both systemsto inter-communicate and provide a weak level of inter-systemauthentication.

[0189] Once the systems are registered, the IKMS operator requests, atstep 528, that IKMS generate some number of preliminary public/privatekey pairs. These key pairs are securely stored in the IKMS database andare tracked (i.e., audited). Once generated, the key pairs are sent tothe operator identified Factory Loader system. The key pairs can be sentvia floppy disk or via e-mail. If the values are sent via e-mail, thee-mail should be encrypted to protect the values in transit. If sent viafloppy disk, they should be physically protected and tracked duringshipment (e.g., sent via registered mail or Federal Express).

[0190] The operator at the Factory Loader receives the preliminarypublic/private key pairs, at step 522, and loads them into the FactoryLoader system. The Factory Loader operator then registers devices, i.e.,equipment types and equipment instances, that are to be initialized andsent to this customer at steps 523 and 524, respectively. Theregistration of devices to be initialized can be manual or can beautomatic. For example, a factory inventory system can automaticallycommunicate the registration information to the Factory Loader. Onceregistered, the Factory Loader operator selects the equipment, selectsone of the preliminary public/private key pairs, and requests theFactory Loader to send it to the equipment (i.e., device) at step 525.Again, this process could be automated to eliminate the need foroperator intervention.

[0191] The database table structure has been designed and built. Thespecific database tables needed for the registration functions have beenbuilt. The registration function tables are the tables that are used tocontrol the overall IKMS operation. In addition to the database tables,a vehicle for interfacing with the database using “stored procedures”has been built and tested. A software interface to an “ORACLE” databasehas been built into the software infrastructure of the IKMS.

[0192] The software necessary to use a customer's existing electronicmail (e-mail) system to move IKMS data between different sites has beenbuilt and tested. This software can interface IKMS to any commercialelectronic mail system that is “MICROSOFT” mail application programinterface (MAPI) compliant. The ability of the IKMS program to send,receive, and forward mail as if it were a human operator has been builtand tested. In addition, the ability to have an operator receivemessages that were forwarded by the IKMS software program has beentested.

[0193] In the process of defining the IKMS, various alternativesolutions have been considered. It should be understood that the IKMScan be implemented using any of a number of computer operating systems,cryptographic hardware accelerators, and software development tools (togenerate software code for the IKMS).

[0194] A preferred embodiment of the IKMS design includes a graphicaluser interface, and a computer operating system that provides someinherent protection to the program and data files that make up the IKMS.The “MICROSOFT WINDOWS NT” operating system was chosen as the firstoperating system in which to implement IKMS. It is anticipated that theIKMS software can be converted to run using a version of the UNIX orsecure UNIX operating systems. Note: It may be advantageous to developall IKMS code in JAVA, as this code is portable to many other operatingsystems. The current embodiment uses C++. We believe that codeimplemented in C++ executes faster than the interpreted JAVA code.

[0195] During the development of IKMS, various methods for moving keymaterial between IKMS accounts and the equipment using the key materialhave been considered. To minimize the effect on existing equipment, IKMSsupports all of the existing key delivery methods for its anticipatedtarget equipment. One of the major advancements of the IKMS is theability to also deliver key material to suitably enhanced equipment viathe remote rekey mechanism. This mechanism allows key material to bedelivered in a secure manner over the existing communications links.

[0196] IKMS accounts can exchange key material to support customerneeds. This exchange can occur via the transfer of removable magneticmedia, via electronic communications using a network protocol, such assimple network management protocol (SNMP), transfer control protocol(TCP), internet protocol (IP), file transfer protocol (FTP), or by usingan electronic mail transfer protocol. Electronic mail distributionprotocol has been selected as the preferred transfer method. This methodwas selected due its adaptability to many different hardware platformsand operating systems. This mechanism also provides a level of controlover data reception and transmission that is lacking in some of theother schemes.

[0197] IKMS is designed to support the commercial data encryptionalgorithms in use today, such as DES, triple DES, RSA, and DSA.Preferably, IKMS can process RSA modulus lengths between 256 and 2048bits. As other algorithms become available for commercial use, they canbe added to the IKMS capability. For example, it is anticipated that theAdvanced Encryption Standard (AES) will be added in the future.

[0198] IKMS saves in a secure but retrievable manner all key materialdistributed to equipment that will be used to encrypt data transactions.In order to support a wide range of customer computer hardware, IKMS hasthe capability to archive the key material at the time it iscreated—before it is distributed to equipment for use. This capabilityrequires no special hardware (other than the storage media drive). Thisarchive scheme begins to affect system and operator efficiency when thesize of the system becomes large. When large amounts of key material arebeing processed, the system allows a more traditional approach to keyarchive. In this approach, RAID technology magnetic disks are used toguarantee the availability of the key material until a convenient timefor the operators to perform a bulk write of the archive key data.

[0199] IKMS is designed to allow a customer to specify a differentcryptographic hardware accelerator for use. The IKMS has a modularizedinterface for communicating with the cryptographic functions. Thismodularization allows the IKMS to operate using a software module toperform cryptographic functions or one of a variety of hardwareaccelerators. Hardware accelerators from Atalla (a Compaq division),Racal, and nCipher have been considered. The preferred embodiment usesthe Atalla WebBanking card (a variation of the WebSafe card).

[0200] IKMS is designed to operate on any computer system that supportsthe chosen operating system and has a minimum set of interfaces,sufficient hard disk space to hold the expected amount of key material,and the internal RAM memory to provide the customer's desiredthroughput.

[0201] The “MICROSOFT WINDOWS NT” operating system has been selected dueto its widespread availability and use. A system for moving key materialbetween IKMS accounts using electronic mail based transfers has beenselected for its wide applicability. The “ATALLA” hardware cryptographicaccelerator module has been selected because of its wide acceptance inindustry and its highly secure architecture.

[0202] Thus there have been described apparatus and methods for managingkey material in heterogeneous cryptographic assets. Those skilled in theart will appreciate that numerous changes and modifications may be madeto the preferred embodiments of the invention and that such changes andmodifications may be made without departing from the spirit of theinvention. It should be understood, for example, that although bankshave been used throughout this disclosure to describe preferredembodiments of the present invention, the usefulness of the presentinvention applies to any organization that utilizes cryptographicdevices to support secure access to data. It is therefore intended thatthe appended claims cover all such equivalent variations as fall withinthe true spirit and scope of the invention.

We claim:
 1. A method for managing key material in cryptographic assets,the method comprising: defining first key material to be delivered to acryptographic asset, wherein the first key material has a cryptoperiodhaving an expiration; defining second key material to be delivered tothe cryptographic asset; and scheduling an automatic delivery of thesecond key material to the cryptographic asset such that the second keymaterial will be delivered automatically to the cryptographic asset ator before the expiration of the cryptoperiod of the first key material.2. The method of claim 1, further comprising: associating a distributionmethod with the cryptographic asset; determining, based on thedistribution method, a minimum lead time required to deliver the keymaterial to the cryptographic asset; and scheduling the automaticdelivery of the second key material to the cryptographic asset based onthe distribution method and on the minimum lead time.
 3. The method ofclaim 1, further comprising: determining whether the key material wassuccessfully delivered to the cryptographic asset; and if the keymaterial was not successfully delivered to the cryptographic asset, thenredelivering the key material to the cryptographic asset.
 4. The methodof claim 1, further comprising: defining a set of equipment classes;registering at least one cryptographic asset with each equipment class;grouping selected cryptographic assets selected from the registeredcryptographic assets into secure communication services, therebydefining secure communication interfaces between the cryptographicassets.
 5. The method of claim 1, wherein defining the first or secondkey material includes receiving the first or second key material from aremote key management system.
 6. The method of claim 1, wherein definingthe first or second key material includes defining a number of keys tobe delivered to the cryptographic asset and, for each key to bedelivered, defining a key type.
 7. The method of claim 1, furthercomprising: encrypting the first or second key material under aprotection key; and storing the encrypted first or second key material.8. A method for managing key material in a plurality of cryptographicassets having a communications interface defined therebetween, themethod comprising: defining a key management interface between acryptographic processor and the cryptographic assets; generating, viathe cryptographic processor, key material to secure the communicationsinterface; and distributing the key material from the cryptographicprocessor to the cryptographic assets.
 9. A method for managing keymaterial for cryptographic assets, comprising: generating, via acryptographic processor, key material for each of a plurality ofheterogeneous cryptographic assets; and distributing the key material tothe heterogeneous cryptographic assets via a key management interfacecoupled to the cryptographic processor.
 10. A method for managing keymaterial in cryptographic assets, comprising: generating first keymaterial having a cryptoperiod; distributing the first key material to acryptographic asset; monitoring the cryptographic asset to determine,based on the cryptoperiod, whether the first key material has expired;generating second key material for the cryptographic asset; and if thefirst key material has expired, automatically distributing the secondkey material to the cryptographic asset.
 11. A method for securing acommunications interface, comprising: defining a set of equipmentclasses; registering at least one cryptographic asset with eachequipment class; grouping selected cryptographic assets selected fromthe registered cryptographic assets into secure communication servicesthereby defining secure communication interfaces between thecryptographic assets; defining key material for each communicationsinterface; and scheduling an automatic delivery of the key material tothe selected cryptographic assets.
 12. Apparatus for managing keymaterial for cryptographic assets, comprising: a cryptographic processorthat generates key material for each of a plurality of heterogeneouscryptographic assets; and a controller having a key managementinterface, that receives the key material from the cryptographicprocessor and distributes the key material to the heterogeneouscryptographic assets via the key management interface.
 13. Apparatus formanaging key material for cryptographic assets, comprising: acryptographic processor that defines first and second key material to bedelivered to a cryptographic asset, wherein the first key material has acryptoperiod having an expiration; and a controller that schedules anautomatic delivery of the second key material to the cryptographic assetsuch that the second key material will be delivered automatically to thecryptographic asset at or before the expiration of the cryptoperiod. 14.Apparatus for managing key material for cryptographic assets, comprisinga computer readable medium having stored thereon computer executableinstructions for: defining a set of equipment classes; registering atleast one cryptographic asset with each equipment class; groupingselected cryptographic assets selected from the registered cryptographicassets into secure communication services thereby defining securecommunication interfaces between the cryptographic assets; defining keymaterial for each communications interface; and scheduling an automaticdelivery of the key material to the selected cryptographic assets.